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APPLYING  KARD'a'ARS  DISCIPLI::ES  to  software  >*JiNAGE:>’.Errr 


STUDY  PROJECT  GOALS:  To  understand,  from  a sysuens  acquisition  viewpoint,  hov; 
certain  proven  hardware  nanacement  disciplines  can  be  used  to  inprove  software 
nanagenent.  To  evaluate  and  explain  the  use  of  configuration  ranagement,  data 
ncnage"ient,  and  design  reviews  in  the  life  cycle  of  software  managcTert. 


STUDY  i’hPOjU,  ABSTKA&T:  A|;tsr  an  Intr^uction,  th-^-  u ur.e 

acquis! cxon  life  cycle.  The  report  outlines  how  a life  cycle  should  be  used  lo 

ip.ar.af'e  the  acquisition  of  software.  Configuration  management  is  intros uceu 

by  rejati:.g  the  configuration  management  '•aselines  to  the  life  cycles.  It 

'’urlher  discusses  the  conf igur" tlon  irenagement  functions  cf  configuration 

Identification,  configuration  control,  an.1  configuration  statiu.s  accoui.ring! 

The  r.'pcrt  strongly  supports  the  use  of  configuration  management  as  a disciplir. 

in  the  ranagement  of  software.  The  report  next  discusses  the  use  of  technical 

reviews  and  audits  in  the  naragerent  of  software.  Finally  the  report  discusses 

what  da.ta  must  be  procured  to  support  a software  system.  The  general  ccnclusio: 

of  the  report  is  that  hardware  disciplines  can  ana  should  he  adapted  and  use^ 

in  the  management  cf  software. 


The  auohor  used  decunents  published  by  the  Department  of  Tefense  and  the  Unite 
Gtates  Air  Foi'Ce  as  guidance  in  presenting  the  material.  However, the  author 
attempted  to  write  the  report  in  general  terms  so  that  Navy  and  Army  oersrnne] 
along  with  Air  Force  personnel  could  read  and  understand  the  report.  Also,  th 
author  hopes  thr.t  persons  familiar  with  the  acquisition  hardware,  but  not 
software,  could  read  this  report  and  begin  to  understand  software  manager, ?nt. 


SUBJECT  DESCRIPTORS 


Softv/are  Management 
Configuration  Control 
Life  Cycle 
Baseline  Management 


Sxecutlve  Sumnary 


The  purpose  of  this  study  project  was  to  further  the  author's 
understanding;  of  software  riianagement  and  to  discuss,  from  a systems  ac- 
quisition viewpoint,  how  certain  proven  hardware  management  disciplines 
can  be  adapted  and  used  to  improve  software  management. 

The  author  used  documents  published  by  the  Department  of  Defense 
and  the  United  States  Air  Force  as  guidance  in  presenting  the  material, 
■lowever,  the  author  attempted  to  write  the  report  in  general  terms  so 
that  Navy  and  Army  personnel,  along  with  Air  Force  personnel  could  read 
and  understand  the  report.  Also,  it  is  hoped  that  persons  familiar  with 
the  acquisition  of  hardware,  but  not  software,  could  read  this  report  and 
begin  to  understand  software  management. 

The  Department  of  Defense  and  the  Military  Services  are  very  con- 
cerned with  the  acquisition  of  software.  They  have  published  many  directives 
regulations  and  standards  that  guide  the  acquisition  of  software.  These 
documents  describe  how  acquisition  life  cycles,  baselines,  configuration 
management,  etc.  can  be  used  to  manage  software. 

Program  managers  can  use  the  same  disciplines  to  manage  software 
as  they  use  to  manage  hardware.  Using  these  management  disciplines  should 
result  in  the  satisfactory  acquisition  of  software. 
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SECTICK  I 


INTFCDUCTION 


Purpose  of  the  Study  Project 

During  recent  years  the  Department  of  Defense  (DCD)  and  the  ser- 
vice components  have  recognized  the  need  for  improved  management  of  soft- 
ware during  acquisition.  This  need  was  outlined  by  Deputy  Assistant  Secre- 
tary of  Defense  Jacques  S.  Gansler  in  the  October  1975  issue  df  the  De- 
Fense  Management  Journal  which  was  devoted  to  software.  His  introductory 
comments  included  the  following  remarks j 

In  recent  months,  managers  in  Defense  and  industry  have  been 
challenged  by  three  important  weapon  system  software  issues j 
the  lack  of  sufficient  control  over  rapidly  growing  software 
expenditures,  the  lack  of  sufficient  research  and  development 
in  software  production,  and  the  need  for  major  improvements 
in  weapon  systems  software  management  (10 il).  * 

In  an  attempt  to  improve  the  management  of  software,  the  Depart- 
ment of  Defense  and  the  service  components  have  initiated  three  types  of 
action  during  the  past  five  years j they  have  held  conferences  on  software; 
and  they  have  published  new  directives  and  regulations  concerning  software. 
The  reports  from  some  of  the  studies  are  listed  in  the  bibliography  to 
this  report.  One  of  the  new  directives  is  DOD  Directive  5000.29,  26 
April  1976,  Subject;  Management  of  Computer  Resources  in  Major  Defense 
Systems.  The  general  policy  stated  in  this  directive  is  as  follows; 

Annual  expenditures  by  DCD  on  the  design,  development, 
acquisition,  management,  and  operational  support  of  computer 
resources  embedded  within,  and  integral  to  weapons,  communi- 
cations, command  and  control,  and  intelligence  sensor  systems 

* This  notation  will  be  used  throughout  the  report  for  sources  of 

quotations  and  major  references.  The  first  number  is  the  source  listed 
in  the  bibliography.  The  second  number  is  the  page  in  the  reference. 


are  measured  in  the  billions  of  dollars.  Unreliability, 
particularly  of  software,  diminished  DCD  mission  effective- 
ness in  many  major  Defense  systems. 

Computer  resources  in  Defense  systems  must  1x3  managed  as 
elements  of  si^bsystems  of  major  importance  during  conceptual, 
validation,  full-scale  development,  production,  deployment, 
and  support  phases  of  the  life  cycle,  with  particular  em- 
phasis on  computer  software  and  its  integration  with  the 
surrounding  hardware  (I2j2). 

Computer  resources  consist  of  two  main  elements i hardware  and  soft- 
ware. The  cost  of  hardware  (computer  equipment)  has  generally  decreased 
over  the  years  as  the  industry  has  learned  new  techniques  and  progressed 
through  several  generations  of  computer  equipment  improvements.  The  cost 
of  software  (computer  programs)  has  Increased  Instead  of  decreased.  In 
certain  cases,  even  after  spending  a considerable  amount  of  funds,  the 
development  of  computer  programs  has  been  unsatisfactory  and  the  final 
programs  have  not  accomplished  their  intended  purpose.  Therefore,  I in- 
tend to  discuss  software  management  in  this  report.  Specif ically, can 
proven  hardware  disciplines  be  adapted  and  applied  to  the  software  ac- 
quisition process? 


Goals  of  the  Study  P.eport 

The  author  of  this  report  had  five  years  of  experience  managing 
software  for  the  Air  Force  Satellite  Control  Facility  in  support  of 
military  satellites.  My  experience  has  been  primarily  in  the  deplo>'m9nt 
phase.  My  division  had  the  responsibility  to  accept  all  computer  programs 
at  the  end  of  the  development/integration  phases,  to  verify  that  the 
computer  programs  were  ready  for  operational  use,  and  to  analyze  all 
problems  that  occured  during  the  operational  use  of  the  computer  programs. 

I had  two  goals  when  choosing  this  study  subject.  The  first  goal 
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was  to  determine  what  current  overall  piiWance  for  manapint^  the  acqulstion 
of  software  had  been  published  by  DOD  and  the  United  States  Air  Force. 

The  second  goal  was  to  further  determine  if  hardware  techniques  could  be 
used  in  software  management. 

My  overall  objective  in  organizing  and  writing  the  report  was  to 
provide  a report  that  a person  not  experienced  in  software  management 
could  read  and  understand.  T believe  that  software  management  is  no  more 
difficult  that  hardware  management.  A manager  new  to  software  management 
should  be  successful  if  he  applies  the  proper  disciplines. 

Definitions 


Computer  Data.  Basic  elements  of  information  used  by  computer  equipment 
in  responding  to  a computer  program  (I2:3ncl  l). 

Computer  Squipment.  Devices  capable  of  accepting  and  storing  computer 
data,  executing  a systematic  sequence  of  operations  on  computer  data  or 
producing  control  outputs.  Such  devices  can  perform  substantial  inter- 
pretation, computations,  communication,  control  and  other  logical  functions 
(I2t3ncl  1). 

Computer  Hardware.  Used  interchangably  with  computer  equipment  in  this 
report . 

Computer  Program.  A series  of  instructions  or  statements  in  a form 
acceptable  to  computer  equipment,  designed  to  cause  the  execution  of 
an  operation  or  series  of  operations.  Computer  programs  include  such 
items  as  operating  systems,  a.ssemblers,  compilers.  Interpreters,  data 
management  system,  utility  programs  such  as  payroll,  inventory  control, 
operational  flight,  strategic,  tactical,  automatic  test,  crew  simulator, 
and  engineering  analysis  programs.  Computer  programs  may  be  either 
machine  dependent  or  machine  independent,  and  may  be  general  purpose  in 
nature  or  be  designed  to  satisfy  the  requirements  of  a specialized  pro- 
cess of  a particular  use  (12:Tncl  1). 

Computer  Program  Maintenance.  The  maintenance  of  a computer  program  is 
defined  to  be  any  modification  to  the  instruction  of  an  operating  digital 
computer  program  or  to  the  documentation  that  describes  the  computer 


profTan.  This  naintenance  r.ay  be  accomplished  for  either  corrective  or 
inprovenent  purposes  and  is  normally  connected  with  the  deployment  pnase 
of  the  life  cycle. 

C omputer  P.es ouj;ces . The  totality  of  computer  equipment,  computer  programs 
computer  data,  associated  documentation,  personal , and  supplies ( 12 1 End  1 

Computer  Software.  A combination  of  associated  computer  programs  and  com- 
puter~data  required  to  enable  the  computer  equipment  to  perform  computa- 
tional or  control  functions  (12:  2nc  l). 

Configuration.  The  functional  and/or  physical  characteristics  of  hard- 
ware/software as  set  forth  in  technica.1  documentation  and  achieved  in 
a pr od  uc  t ( 14 : ’4-1 ) . 

Configuration  Control,  'd'he  systematic  evaluation,  coordination,  approval 
or~d.isapproval,  and  implementation  of  all  approve’  changes  in  the  con- 
figuration of  a Cl  after  formal  establishment  of  its  configuration  iden- 
tification (l4:4l). 

Configuration  Item  (Cl).  An  aggregation  of  hardware/sof twarc , or  any  of 
its  discrete  portions, which  satisfies  an  end  use  function  and  is  de- 
signated by  the  Government  for  configuration  management.  CIs  may  vary 
widely  in  complexity,  size  and  type  (I4:';l). 

Configuration  Management.  A discipline  applyineg  technical  and  adminis- 
trative direction  and.  surveillance  to  (l)  identify  and  document  the  func- 
tional and  physical  characteristics  of  a configuration  item,  (2)  control 
changes  to  those  characteristics,  and  (3)  record  and  report  change  pro- 
cessing and  implementation  statics  (l-':42). 

Contract  Data  hequireraents  List  (CD2L).  A contract  form,  DD  1423#  listing 
all  technical  data  items  and  status  data  items,  selected  from  an  Author- 
ized Data  List,  to  'oe  delivered  under  the  contract. 

Data  (Technical).  The  means  for  communication  of  concepts,  plans_^des- 
criptions,  requirements,  and  instructions  relating  to  technical  projects, 
material,  systems,  and  services.  These  may  include  specifications, 
standards,  engineering  drawings,  associated  lists,  manuals,  and  reports, 
including  scientific  and  technical  reports;  they  may  be  in  the  form  of 
docaments,  disnlays,  records,  punched  cards,  and  digital  or  analogy  data 
(14:42). 

Data  ( Status ) . The  means  for  communication  of  status  on  a program/project 
These  may  include  reports  on  funds,  cost  expenditure, cost  forecasts, 
schedules,  schedule  forecasts,  agendas  for  meetings,  etc. 
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Docunentation.  The  specifications,  reports,  plans,  and  procedures  used 
to  document  and  support  computer  programs ( 6 : 4 ) . 

Imbedded . Adjective  modifiers  integral  to,  from  the  design,  procurement, 
and  operations  point  of  view  expoused  in  DOD  Directive  5000.1  (I2:lncl  l). 

hardware  System.  The  totality  of  a system  of  hardware  including  the  hard- 
ware, associated  documentation,  personnel  and  logistics. 

Software  Inginecring.  Science  of  design,  development.  Implementation,  test, 
eval'jation,  and  maintenance  of  comnuter  software  over  its  life  cycle 
{12 t 3ncl  1). 

Softv.’are  System.  The  totality  of  a system  of  software  including  the 
software,  associated  docamentation,  personnel  and  logistics. 

Organization  of  the  Study  Peport 

In  addition  to  this  introd-uctory  section,  the  report  has  been  or- 
ganized into  four  sections  and  a summary  section.  The  reader  will  possibly 
want  to  read  the  summary  section  before  he  reads  the  other  four  sections. 

Section  II  dea.ls  with  the  life  cycle,  "irst,  the  acquisition  life 
cycle  is  discussed;  secondly,  additional  life  cycles  as  they  relate  to 
software  are  discussed;  this  is  followed  by  the  author's  recommended  life 
cycle,  finally  the  section  brings  out  some  important  items  to  consider 
during  each  phase  of  the  life  cycle. 

Section  III  deals  with  configuration  management.  This  section  be- 
gins with  some  general  comments,  followed  by  some  comments  on  baseline 
management.  Finally  the  configuration  management  functions  of  configuration 
identification,  configuration  control,  and  configuration  status  accounting 
are  discussed. 

Section  IV  deals  with  technical  reviews  and  audits.  This  section 
begins  with  general  comments,  followed  by  a discussion  of  each  type  of 
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fornal  technical  revlev;  and  formal  audit. 


Section  V deals  with  the  manacenent  of  technical  and  status  data. 


This  section  beftins  with  general  comments,  followed  by  a section  that 


discusses  the  need  for  data/documentation.  Finally  the  section  dis- 
cusses some  specific  software  data  items. 

Section  VI  is  the  summary  containing  conclusions  and  recommendations. 


SECTION  II 


T'r[2  LIFE  CYCLE 
?he  Acquisition  Life  Cycle 

The  acquisition  process  nomally  uses  a life  cycle  to  provide 
the  basis  for  catecorizinc  program  mananenent  activities.  In  general  the 
cycle  is  divided  into  five  phases:  conceptual,  validation,  full-scale 
development,  production,  and  deployment  phases,  "'his  is  the  life  cycle 
commonly  used  to  acquire  hardware.  A brief  description  of  each  phase  is 
provided  in  the  paragraphs  below. 

During  the  conceptiaal  phase,  the  tecJmical,  military  and  economic 
'oases  are  established  through  comprehensive  studies,  experimental  develop- 
ment and  concept  evaluation.  The  management  approach  is  also  forrriulated 
durlm,g  t’mis  phase.  During  the  validation  phase  the  major  program  character- 
istics are  validated  and  refined  through  studies,  system  engineering  and 
preliminary  development,  test  and  evalmtion.  Program  risks  and  costs 
are  assessed,  resolved  or  minimized. 

Luring  the  full-scale  development  phase,  the  system  is  designed, 
fabricated,  tested  and  evaluated.  The  test  results  demonstrate  t'mat  the 
system  meets  the  stated  performance  requirements.  Costs  are  continually 
assessed.  During  the  production  phase,  the  system  is  produced  and  de- 
livered as  an  effective,  economical,  and  supportable  system.  Transition 
from  the  acquisition  to  th.e  operation  and  support  commands  'oegins. 

During  the  deployment  phase,  the  system  is  used  operationally.  This  phase 
terminates  when  the  system  is  removed  from  the  operational  inventory. 


ether  Software  life  Cycles 


In  researching  documentation,  the  author  noted  that  several  doc- 
uments listed  the  names  for  the  steps  or  phases  for  the  acquisition  of 
software  to  be  different  from  the  names  used  in  normal  hardware  acquisi- 
tion cycle.  Three  of  these  software  life  cycles  (there  are  more)  are 
discussed  below. 

A?  '^erulation  800-14  lists  the  life  cycle  for  computer  prograr. 
development  in  six  phases*  analysis,  desicn,  coding  and  checkout,  test 
and  integration,  installation,  and  operating  and,  support  phases  (lj2-3). 
These  phases  can  be  related  to  the  major  acquisition  phases.  For  example, 
the  analysis  phase  corresponds  partly  to  the  conceptual  phase,  and  the 
operational  and  support  phase  corresponds  to  the  deployment  phase. 

In  the  past,  the  Space  and  Missile  Systems  Organization  used  a 
milestone  system  for  development  of  computer  programs.  These  development 
milestones  are  outlined  in  SSD  Exhibit  61-47  B (5»3)»  The  milestones 
were  named  or  expressed  in  terms  of  the  product  available  at  the  end  of 
each  milestone.  The  eight  milestones  were*  design  criteria,  implemen- 
tation concept  and  test  plan,  interface  specifications,  design  and  accep- 
tance specifications,  computer  programs,  computer  program  subsystem  vali- 
dation plan,  computer  program  operation  instructions,  computer  prot^am 
subsystem  and  model  capabilities.  This  is  the  system  that  the  Air  Force 
Satellite  Control  Facility  was  using  when  the  author  first  became  in- 
volved with  software.  These  milestones  can  be  related  to  the  other  life 
cycles.  For  example,  the  design  criteria  is  the  product  of  a conceptual 
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r’he  Air  Force  has  recently  written  a docanent  for  use  as  a ?^uide 
in  the  development  of  software,  "’his  guide,  with  the  title  "Air  Force 
ADP  Software  Project  I'anual" , lists  the  following  five  development  phasesi 
conceptual,  definition,  development,  integration,  and  operational  (3:2-1). 
These  phases  can  he  directly  related  to  the  five  major  acquisition  phases, 
'■'or  example,  the  definition  phase  corresponds  to  the  validation  phase. 

Authors  Peconnended  Software  Life  Cycle 
The  acquisition  life  cycle  can  he  used  to  define  the  phases  of 
software  acquisition  as  well  as  hardware  acquisition,  however,  the  fourth 
phase,  production  does  not  liave  a significant  meaning  in  software  ac- 
quisition. fo  make  additional  copies  of  the  master  computer  program  is 
very  simple.  In  software  acquisition  this  p’nase  consists  mainly  of  test- 
ing, not  prod.uction.  In  hardware  acquisition  hoth  production  and  testing 
of  the  product  is  a significant  effort.  Therefore,  for  software  acquisitlo:. 
it  is  suggested  that  the  life  cycle  consists  of  the  follovfing  five  phases s 
conceptml,  validation,  development,  inte^-pration,  and  deplo^nent.  The 
aut'n.or  helieves  that  hy  using  t’-icse  icames  a manager  new  to  software  ac- 
quisition co.n  easily  relate  softw’are  acquisition  to  his  experience  in  hard- 
v;are  acquisition. 

Figure  I displays  how  the  different  life  cycles  can  be  compared  to 
each  other.  A nuanager  should  evaluate  ’nis  situation,  choose  an  appro- 
priate life  cycle,  and  tailor  his  situation  to  that  cycle.  It  isn't  im- 
portant vrhat  name  is  given  to  each  phase;  however,  it  is  extremely  im- 
portant that  a life  cycle  be  used  to  manage  the  software  project.  A life 
cycle  helps  the  manager  think  through  the  software  acquisition  process. 

9 





LIFE  CYCLES 


A life  cycle  enables  the  manager  to  detcrnine  what  .'nanacenent  steps  need 
to  be  taken  and  when  to  take  these  steps. 
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A specific  policy  from  BCD  Directive  5C00.29  is  as  followsj 

Specific  milestones  to  manage  the  life  cycle  development  of 
computer  system  and  support  software  will  'oe  used  to  ensure 
the  proper  sequence  of  analysis,  desi"n  implmentatlon,  In- 
te.'pration,  test,  documenta.+  ion,  operation,  maintenance,  and 
modification.  These  milestones  will  include  specific  criteria 
that  measure  their  attainment  (12:3). 

Life  Cycle  Phase  Considerations 

In  order  to  be  successful  in  acquiring  software,  there  are  many 
items  to  consider  in  each  phase.  Based  on  the  author's  experience  a few 
items  vfill  be  discussed  below  that  a.ppear  to  be  significant. 

In  the  conceptual  phase  the  key  item  is  to  properly  define  the 
functional  performance  requirements  for  the  computer  programs.  The  needs 
and  mission  requirements  of  the  user  must  be  properly  stated  in  a design 
criteria  document  or  general  specification.  To  properly  accomplish  this 
phase  the  user  must  be  involved.  This  phase  must  be  properly  accomplished 
or  the  next  phases  will  either  fail  or  become  excessively  costly. 

Also  in  this  phase  the  maintenance  concept  should  begin  to  be  for- 
mulated. A maintenance  concept  is  as  important  for  software  as  it  is  for 
hardware,  ’.vho  is  going  to  modify  the  computer  programs  in  the  deployment 
phase?  ’.ihn  is  going  to  analyze  problems  and  program  solutions  to  the  pro- 
blems? In-service  personnel?  Contractor  personnel?  Kow  is  the  config- 
uration of  the  operational  programs  going  to  be  controlled?  If  in-service 
personnel  are  going  to  maintain  the  software  then  appropriate  decumentation 
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and  training  must  be  provided  by  the  contractor.  These  items  must  be 
written  into  the  contract  for  the  development  phase.  Planning  should  be- 
gin in  the  conceptual  phase  and  an  initial  maintenance  concept  should  be 
f ormulated . 

In  the  validation  phase  a key  item  to  be  considered  is  the  hardware/ 
software  interface,  './hat  size  computer  is  going  to  lie  used?  How  much 
core  does  the  computer  have?  Can  additional  core  be  added,  if  needed? 

If  not,  does  the  proposed  system  present  an  undesireable  risk?  How  fast 
is  the  computer?  Is  the  computer  fast  enough  to  accomplish  any  required 
real  time  processing?  Also  decisions  regarding  the  type  of  language  must 
be  made.  Is  a High  Order  Pro..n:amming  Language  going  to  be  used?  Or,  is 
a machine  language  going  to  be  used?  The  risk  areas  must  be  identified, 
and  a plan  for  their  resolution  must  exist  by  the  end  of  the  validation 


phase. 


The  development  phase  seems  to  have  two  key  items  that  lead  to 


success.  The  first  is  to  have  well  run  Preliminary  Design  Reviews  and 
Critical  Design  Reviews.  If  possible,  the  user  should  take  part  is  these 
reviews.  The  second  key  item  is  to  keep  the  number  of  changes  to  be  a 
minimum.  A development  schedule  cannot  be  maintained  if  changes  are  con- 
stantly made  to  the  allocated  baseline.  At  times  it  is  absolutely  necessary 
to  freeze  the  baseline  and  hold  all  changes  to  a later  model. 

The  Integration  phase  consists  of  integration  and  testing  of  the 
computer  programs  in  the  operational  environment.  This  testing  is  either 
accomplished  by  the  developer  or  by  an  Independent  test  organization 


(inservice  or  independent  contractor).  Therefore,  the  first  decision 
to  be  nade  is  to  decide  who  is  goinp;  to  accomplish  the  tests.  The  key  to 
a successful  integration  phase  is  to  make  the  tests  as  realistic  and  close 
to  the  operational  situation  as  possible.  For  a large  program  all  possible 

i 

situations  cannot  be  tested  (cost  prohibits  this);  thus  good  judgement  1 

must  be  made  regarding  what  situations  are  tested.  During  the  testing, con- 
figuration control  must  be  maintained.  It  is  absolutely  necessary  to  know 
what  program  configuration  is  being  tested.  'j 

i 

More  money  can  be  spent  in  the  deployment  phase  than  any  other  j 

phase  if  the  computer  programs  are  constantly  changed.  Computer  programs  j 

can  be  easily  changed;  however,  each  change  can  cause  unknown  problems  in  j 

i 

other  parts  of  the  program.  Therefore,  each  change  needs  to  be  tested.  | 

1 

Program  changes  that  correct  known  problems  must  also  be  tested  as  they 
could  cause  unknown  problems.  Sach  change  made  to  improve  the  program 
should  be  fully  justified  before  it  Is  approved.  All  of  the  above  can  be  3 

summarized  in  two  simple  statements j Configuration  control  is  vital  for 
proper  software  management  in  the  deployment  phase.  Testing  of  soft- 
ware changes  must  occur  before  they  are  added  to  the  operational  software. 
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COTIGUPATICK  MAVACa^'S!;? 

General  Gomments 

Kost  readers  are  aware  how  the  discipline  of  configuration  nanare- 
Tient  is  used  in  the  mar^^^enent  of  hardware  systems.  Some  readers  are  not 
aware  that  the  sane  discipline  can  be  and  should  be  applied  to  the  manage- 
ment of  software  systems.  The  principles  of  configuration  management  are 
used  by  commercial  concerns  as  well  as  the  military,  irfhen  you  order  a 
part  to  repair  your  car,  you  receive  a part  that  fits  because  the  principles 
of  configuration  management  are  used  by  the  automobile  industry.  sTien  a 
commercial  firm  uses  a computer  throug,h  a time  sharing  arrangement,  they 
get  results  from  this  rented  time.  To  Insure  results,  the  configuration 
of  the  computer  programs  loaded  on  the  computer  are  known  and  controlled, 
’fhen  the  students  at  DSMG  use  the  computer  terminals  for  System  X analysis, 
the  output  from  the  computer  is  predictable  by  the  instructor  because  the 
computer  programs  loaded  on  the  computers  are  consistant  with  the  opera- 
tional guide  provided  to  the  students.  These  are  examples  of  applying  con- 
figuration management  to  software. 

DCD  Directive  5000.29  directs  that  the  discipline  of  configuration 

management  be  applied  during  software  acquisitions  for  major  programs.  A 

specific  policy  statement  from  the  directive  is  as  followsi 

Defense  system  computer  resources,  including  both  computer 
hardware  and  computer  software  will  be  specified  and  treated 
as  configuration  items  (12 i2). 

According  to  the  definition  in  Section  I,  Configuration  management 
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consists  of  three  functions:  configuration  identif ication,  configuration 


change  control,  and  configuration  status  accounting.  Before  further  dis- 
cussion of  these  functions  a discussion  of  haseline  rmnagenent  is  appro- 
priate. Certain  questions  need  answering,  ’.fnat  criteria  do  you  identify 
ag;ainst?  VH^at  do  you  chai'.ge  from? 

Baseline  Kanagenent 

'fhe  definition  of  baseline  management  as  found  in  AFT:  £0C-l4  is: 

A fundamental  concept  associated  with  engineering  management 
is  the  use  of  a series  of  configuration  management  baselines 
which  aid  in  assuring  an  orderly  transitional  from  one  major 
decision  point  to  the  next  throughout  the  system  acquisition 
life  cycle  (l:  b-i). 

Kost  documents  list  three  baselines:  functional,  allocated,  and 
product,  ""nese  baselines  can  be  directly  related  to  the  life  cycles  as 
discussed  in  section  II.  The  functional  baseline  marks  the  end  of  the 
conceptual  phase  and  the  start  of  the  validation  phase.  Toe  functior^al 
baseline  is  established  by  the  system  specification  (Type  A).  The  allo- 
cated baseline  marks  the  end  of  the  validation  phase  and  the  start  of  the 
development  phase,  "'’he  allocated  baseline  is  established  by  a lievelop- 
ment  specification  (Type  ?5).  The  product  '!)aseline  marks  the  end  of  the 
development  phase  and  the  start  of  the  integration  phase.  The  product 
baseline  is  established  by  the  pra'uct  specification  (Tjq>e  C5). 

The  Air  force  ADP  ooftware  Project  !;a.nual  recomjnencs  the  use  of  a 
fourth  baseline  for  software  ma.r.agement . The  aut;'*or  agrees  that  a fourth 
baseline  is  needed.  This  baseline  can  be  called  the  opera.tional  baseline, 
nie  opera.ti.onal  baseline  marT'.s  the  end  of  the  integration  phase  a.nd  the 

1=^. 


start  of  the  deployment  phase,  "'he  operational  baseline  is  established 
by  the  product  specification  plus  a list  of  all  discrepancies  ajjainst  the  ! 

software.  A discrepancy  describes  a problem  that  prevents  the  computer  j 

program  from  totally  neetinp  some  part  of  the  product  specifications. 

The  discrepancies  are  of  the  tj^pc  that  can  he  "worhed  around"  during  the  ^ 

deployment  phase.  If  the  discrepancy  (ies)  is  (are)  severe  enought  to 

prevent  the  operational  use  of  the  program,  tlie  computer  program  must  be 

returned  to  the  pro~rammer  and  the  problems  must  be  corrected.  Tliis  will 

also  require  a partial  or  total  reaccomplishment  of  the  testing  that  is  i 

accomplished  In  the  integration  phase. 

Tt  is  almost  impossible  to  deliver  software  vrithout  discrepancies. 

!!ost  large  comnuter  programs  will  have  several  discrepancies  listed  against 
them  at  the  end  cf  t'ae  intefTration  phase.  Schedules  usually  require  the 
advancement  to  t.'.e  deployment  p'lase  before  all  discrepancies  are  resolved. 

This  is  the  reason  an  operational  'rxisoline  is  needed.  During  f.ie  deploy- 
ment phase  a computer  program  will  advance  from  one  operational  'oaseline 
to  other  operationa.l  "oaselines  as  softvraro  maintenance  is  accomplished. 

Each  one  of  these  baselines  must  be  properly  controlled  using  configuration 
management  procedures.  ' 

Configuration  Identification  ^ 

Configuration  identification  provides  the  specific  technical  des-  i 

cription  of  an  item  at  any  point  in  time.  This  identification  is  accom-  j 

plished  by  using  baseline  documentation.  As  the  software  d.evelopment  pro-  i 

gresses  through  the  life  cycle,  the  description  of  the  computer  program  ' 
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beco."!es  increasinr  c’etailed. 

■^aseline  clocur.er.taticn  ucod  for  conf I'jii.rT+.ior.  idc-rti'^'lcatlor.  in- 
cludes: systen/subsysten  specifications,  dcvelopricnt  specifications,  pro- 
duct specifications,  interface  specifications,  and  co.'.putcr  data  req^uix'e- 
nsnts  docunents.  Interface  specifications  describe  either  software  to 
software  or  software  to  '.•.art.'warR  interfaces. 

data  requirenents  docunents  list  a.nd  define  cp.ta  elements  that  the 
cosiputex’  pro^^rar.  nust  lianclle.  ‘'he  us.er  nust  be  involved,  in  specifying 
these  data  olenents. 

jpeciflcation  trees  are  used  to  i'^entify  conputer  program.  Cor.puter 
pro-^ra'is  can  be  brohen  down  to  lower  levels.  At  the  betton  level  the  r.ar.e 
routine  is  used.  "Vo  or  nore  routines  car.  be  combined  to  f orn  a nodule. 

Two  or  nore  nodules  can  be  conbined  into  a conputer  pro;-pran  co.npcnent.  T'we 
or  .nore  co.nputer  pro.^pran  conpononts  car.  be  conbined  into  a conputer  procra.n 
conf iruratlon  iten  (TFGI).  A nunberln*;  system  is  needed  to  control  and  to 
facilitate  traceability  cf  CFCIa  throufjh  out  a x^ropran's  lifetlne. 

Gonfipuration  Control 

Configuration  control  is  f'.e  systematic  evaluation,  coordination, 
approval  or  disapproval,  and  inplenentatio.n  of  all  approved  changes  in  the 
configuration  of  a CFCI  after  fornal  establishment  of  the  baseline.  _oti! 
the  conputer  progran  and  the  documentation  that  describes  the  conputer 
progran  nust  be  controlled. 

engineering  changes  to  hardware  are  classified  as  Glass  I or  Glass 
IT  changes.  Tnese  same  classifications  can  be  user  in  corif iguration  con- 
trol of  software.  Glass  I changes  are  those  changer,  that  change  a techni- 


cal  description  listed  in  a baseline  specification.  Class  II  chang-es 
are  changes  that  are  not  Class  I changes.  Class  II  changes  in  software 
management  are  those  made  to  non  baseline  documentation  such  as  changes 
to  the  users  manual . This  author  also  recommends  that  any  program  change 
that  is  made  to  correct  a discrepancy  while  in  the  deplojnnent  phase  be 
listed  and  controlled  as  a Class  II  change.  Computer  Program  changes 
that  correct  discrepancies  must  be  properly  integrated  and  tested  before 
they  are  allowed  to  be  Incorporated  into  the  master  operational  computer 
program.  Configuration  control  in  the  deployment  phase  is  absolutely 
necessary.  I recommend  that  formal  configuration  control  boards  to  con- 
trol software  be  established  at  the  same  point  in  the  acquisition  cycle 
as  the  configuration  control  board  is  established  to  control  hardware. 

This  is  normally  at  the  tine  of  critical  design  r'eview. 

Configuration  Status  Accounting 

Configuration  status  accounting  is  the  recording  and  reporting  of 
a CPCI’s  initially  approved  configuration  identification  and  of  all  pro- 
posed  and  approved  changes  to  the  configuration  identification.  Status 
accounting  begins  when  the  first  specification  for  a computer  pro.gram  is 
approved  and  released  and  continues  throughout  the  life  cycle  of  the  soft- 
ware system. 

Configuration  status  accounting  must  also  include  recording  and 
reporting  of  all  software  problems  (discrepancies).  Records  must  contain 
traceability  of  all  software  problems  tc  their  corrective  action.  If,  ir. 
the  deployment  phase,  more  thn  one  software  mo^Iel  is  in  use,  then  con- 
figuration status  accounting  and  reporting  of  each  model  must  occur. 
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':'H:G-r::iCAL  P-HT/isv/s  a::d  audios 

General  Gonunents 

Durlnj  the  mana^'ement  of  a software  project,  several  formal  re- 
views and  audits  should  be  held  with  the  contractor(s) . These  reviews 
begin  in  the  conceptual  phase  and  continue  through  the  integration  phase. 
These  reviews  and  audits  need  to  be  directed  by  appropriate  words  in  the 
contract.  As  the  formal  reviews  and  audits  will  not  provide  all  the  in- 
formation needed  to  manage  a software  project,  the  formal  reviews  must  be 
aufmiented  by  several  additional  meetings  between  the  contractor  and  the 
program  management  organization. 

In  this  section  the  following  reviews  will  be  discussed  t System 
requirements  Review  (SR?.),  System  Design  Review  (SDR),  Preliminary  Design 
Review  (PDK),  and  the  Critical  Design  Review  (ODP).  Also  the  Functional 
Configuration  AutUt  (FCA)  and  the  Physical  Configuration  Audit  (PCA)  will 
be  examined.  Many  persons  have  experience  using  these  reviews  and  audits 
in  hardware  projects.  These  sane  reviews  and  audits  can  be  easily  adapted 
and  used  to  manage  software. 

Technical  Reviews 

Most  of  the  following  definitions,  comments,  and  discussion  comes 
directly  from  MIL- STD  - 1521  (20:4). 

The  objective  of  the  SRP  is  to  ascertain  the  adequacy  of  the  con- 
tractor's efforts  in  defining  system  requirements.  It  will  be  conducted 
when  a significant  portion  of  the  system  functional  requirements  have  been 
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: established.  The  S^R  should  be  conducted  In  the  validation  phase  if  the 

contractor  has  not  been  involved  in  the  conceptual  phase.  The  user  should 
^ be  involved  in  this  review  if  possible. 

The’  objective  of  the  3DE  is  to  eval'Jate  the  optinization,  trace- 
ability,  correlation,  completeness,  and  risk  of  the  allocated  baseline. 

The  3DP  should  be  the  final  review  before  submittal  of  the  validation 
phase  products.  This  review  should  be  in  sufficient  detail  to  insure  a 
technical  understanding  between  the  contractor  and  the  program  management 
' organisation.  The  SDP.  should  result  in  the  identification  of  all  computer 

; programs  required  throughout  the  system.  The  computer  programs  consist  of 

operational  programs,  mainteruince/diagnostic  programs,  test/debug  programs, 

‘ exercise  and  analysis  programs,  simulation  programs,  compilers  and  assemblers. 

The  computer  program  language  to  be  used  should  be  identified  in  the  3D?.. 

k 

: i 

I Finally  all  computer  facilities  needed  to  support  the  development  of  com- 

puter programs  in  the  next  phase  should  be  identified. 

The  objective  of  the  PDF  is  to  evaluate  the  progress  and  techdcal 
adequacy  of  the  selected  design  approach,  to  determine  the  compatibility  of 
t-  the  design  approach  with  the  performance  requirements  of  the  CPCT  develop- 

f ment  specification,  and  to  determine  the  compatibility  between  the  CPCI 

■ - ■ and  other  hardware  or  software  items.  The  PDF.  at  approximately  the  i 

point  in  time  of  the  development  phase. 

According  to  Mil- STD-1521,  the  following  should  be  considered  at 

PD’’'. 


Somnuter  Proforam  functional  Flow.  This  information  shall 


be  completed  to  t'le  level  of  flow  chartinc  which  identifies 
the  allocation  of  computer  prorpran  components  to  functions  and 
depicts  the  sequence  of  operation  within  tne  system  functional 
flow. 

Storafje  Allocation  Charts.  ^:is  information  shall  be  detailed 
for  the  GPCI  as  a whole,  describing:  the  manner  in  which  avail- 
able storage  is  allocated  to  individual  computer  programs. 
Timing,  sequencing  requirements,  and  relevant  equipment  con- 
straints used  in  determining  the  allocation  are  to  be  included. 

Control  Functions  Description.  A description  of  the  exe- 
cutive control  and  start/recovery  features  for  the  computer 
program  system  shall  be  available,  including  method  of  ini- 
tiating sj'stem  operation  and  features  enabling  recovery  from 
system  malfunction. 

Gtructuro  and  Organization  of  the  Data  ?asc.  ;he  data  base 
description  shall  be  completed  to  a level  which  identifies 
data  types  and  characteristics,  structure  layout,  and  allo- 
cation of  data  storage  (20ii9). 


Formal  Audits 

Fost  of  the  following  definitions,  comments,  and  discussion  come 
directly  from  MIL- STD-1524  (80 j4). 

The  FCA  is  held  to  verify  that  each  CPCI  has  achieved  the  per- 
formance specified  in  the  development  specification  (allocated  baseline). 
Then  verification  is  accomplished  by  examining  and  reviewing  test  data. 

The  FCA  is  a prerequisite  to  acceptance  of  the  development  effort. 

'Tne  PCA  is  a formal  examination  of  the  coded  version  of  a CPCI 
against  its  technical  documentation,  and  of  the  configuration  management 
record.s  to  establish  the  proc’uct  baseline.  The  PCA  should  not  be  conducted 
unless  the  program  management  organization  has  the  final  draft  of  the  pro- 
duct speci*'ication.  The  Ff"A  includes  a detailed  audit  of  the  product 
specification,  including  ibs  flow  charts,  listings,  and  design  narrative. 
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STCTIC’I  V 

ha::ag3isi«t  of  data 

General  Comments 

A harnware  syste.m  consists  of  hardware,  documentation , personnel, 
etc.  A software  system  consists  of  the  computer  software,  documentation, 
personnel,  etc.  Data  (technical  and  status)  is  required  to  manace  the 
acquisition  of  software  and  to  support  that  software  in  the  deployment 
phase.  A software  system  is  no  more  supportable  without  documentation 
than  a hardware  system  would  be  without  a technical  manual. 

The  computer  program,  just  like  a hardware  item,  is  acquired  using 
a contract  which  includes  a statement  of  work  (SOW)  and  a contract  data 
requirements  list  (CDP.L).  The  computer  program  is  produced  and  delivered 
in  accordance  with  the  SCT.  Documentation  to  support  the  computer  program 
is  delivered  in  accordance  with  the  CDHL,  The  DCD  has  an  authorized  data 
list  (ADI.)  which  identifies  standard  data  item  descriptions  (DIDS)  for 
us  in  acquiring  data  from  contractors.  The  DIDS  should  be  tailored  to 
actual  requirements. 

Why  Document? 

DCD  Directive  5000*29  directs  that  support  items  needed  to  main- 
tain computer  programs  be  specified  in  the  contract  and  delivered.  A 
specific  policy  statement  from  the  directive  is  as  follows: 

Unique  support  items  required  to  cost  effectively  develop 
and  maintain  the  delivered  computer  resources  over  the  systems 
life  cycle  will  be  specified  as  deliverable,  with  DCD  acquir- 
ing rights  to  their  design  and/or  use,  Dxamples  of  such  sup- 
port items  are  compilers,  environmental  simulators,  documenta- 


tion  aids,  test  case  generators  and  analyzers,  and  train- 

alds(l2:3). 

Volame  II  of  AP'P.  800-1^1-  states  that  each  phase  of  development 

should  1)0  docmented.  It  lists  the  needs  for  documentation  as  follows! 

Documentation  Is  needed  during  development  in  order  to 
track  progress  and  provide  information  for  management 
visibility  and  decision  making.  For  example,  specifications 
are  required  to  describe  the  computer  equipment  and  computer 
programs  in  terms  of  design  performance,  configuration  and 
test  requirements. 

Documentation  is  needed  to  enable  proper  life  cycle  support 
and  maintenance  of  th,e  computer  resources.  This  documentation 
should  be  maintained  and  updated,  as  required,  for  each  change 
to  the  system  or  system  operation  (li?-!). 

Docunentatlnn  is  also  important  to  a software  system  because  of  a 
unique  software  situation.  The  profprajnmingof  software  is  somewhat  an  "art". 
No  two  programmers  would  program  a software  routine  the  sarnie.  Therefore, 
how  the  routine  is  programmed  must  be  documented.  A few  key  programmers 
could  have  accomplished  a significant  portion  of  the  programming  for  any 
software  system.  Their  efforts  must  he  documented  to  prevent  the  possi- 
bility of  a personnel  turnover  that  would  cause  an  unacceptable  risk  to  the 
program . 

Software  Data  Items 

Some  of  the  sane  data  Iteiiis  that  are  required  from  a hardware  con- 
tractor will  he  required  from  a software  contractor.  Examples  aret  Contract 
^und  Status  "Reports,  Con‘'iguration  Kanagement  Flan,  Engineering  Change  Pro- 
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posals.  Specification  Change  Notices,  'Contract  Vork  breakdown  Structure. 


Gone  of  the  support  clocunentation  required  to  j^rovide  additional 
desi^^n,  test  and  operation  information  or.  a software  prof:ram  are  listed  be- 
low. Generally  all  of  these  will  be  produced  while  developing  a software 
system. 

Data  Fequirements  Document.  Lists  and  defines  co.mputer  data  ele- 
ments that  the  computer  program  must  handle,  including  data  elements  that 
the  user  must  supply  (3«--f-15)* 

Data  Pase  Specification.  Specifies  storage  allocation  and  data 
base  organization  in  sufficient  detail  to  permit  programmers  to  co-le  the 
computer  program  and  to  generate  required  files,  tables,  dictionaries,  and 
directories 

Computer  Operators  Manual.  Specifies  in  detail  the  external 
chacteristics  of  a program  and  the  procedure  for  initiating,  executing,  and 
terminating  it.  Describes  each  computer  program  function,  including  inputs, 
outputs,  relationship  with  other  functions,  and  the  operating  Instructions 
for  running  the  function,  with  linitations,  restrictions,  error  messages, 
probable  cause,  recovery  procedure,  methods  for  estimating  run  time,  etc. 
(3j4-17). 

Program  Maintenance  Manual.  Contains  detailed  instructions  and 
procedures  for  maintaining  and  updating  the  software  product  during  the 
operational  phase  (3«4-17). 

Programmer  Notebooks.  Provides  a development  record  and  trace- 
ability  data  relative  to  the  design,  debugging,  checkout,  and  integration 
of  routines,  modules,  and  functions  of  the  CPCI.  (fote«  This  item  might 
not  be  a delivered  item)  (3«4-l8). 
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Conclusions 

The  Department  of  Defense  and  the  Military  Services  are  very 
concerned  with  the  acquisition  of  software.  This  is  evident  by  the  number 
of  studies  authorized.  Studies  have  been  conducted  by  the  Joint  Logistics 
Commanders  Software  Reliability  Work  Group,  United  States  Air  Force  Project 
Rand,  Industrial  College  of  the  Armed  Forces,  United  States  Air  Force  Pro- 
ject Pacer  Flash,  and  the  John  Hopkins  University  Applied  Physics  Labora- 
tory. 


Many  directives,  regulations  and  standards  are  currently  publish- 
ed that  guide  the  acquisition  of  software.  Guidance  provided  in  these  doc- 
uments is  generally  good  and  consistent.  Some  of  the  documents  are  hard  to 
read  and  understand,  especially  for  someone  without  prior  knowledge  of  soft- 
ware management. 

Many  disciplines  that  have  been  applied  to  hardware  acquisition 
can  be  adapted  and  applied  to  software  acquisition.  However,  they  generally 
need  to  be  tailored  to  fit  the  exact  situation  (embedded  or  stand  alone 
software  project,  small  or  large  size  procurement). 

The  life  cycle  can  be  used  to  manage  software.  The  names  used  for 
each  phase  can  vary  with  the  situation.  A software  maintenance  concept 
should  be  identified  early  in  the  life  cycle.  Software  maintenance  will 
be  required  in  the  deployment  phase. 

Conf igtiration  management  should  be  used  as  an  aid  in  the  acqui- 
sition of  computer  programs.  Configuration  management  must  continue  to  be 
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applied  in  the  deployment  phase. 

Technical  reviews  and  audits  provide  the  program  manager  with 
the  needed  information  required  to  make  management  decisions.  The  same 
general  reviews  and  audits  that  are  used  in  hardware  acquisition  should 
be  used,  in  software  acquisition. 

Procument  of  data  to  support  a computer  program  is  necessary; 
without  this  data  (documentation)  the  systems  would  be  incomplete. 
Documentation  is  needed  to  manage  during  the  acquisition  phases  and  to 
support  the  system  during  the  deployment  phase. 

Software  acquisition  can  be  properly  managed.  The  necessary 
disciplines  are  available  for  use. 

Recommendations 

1.  That  Program  Managers  use  the  same  disciplines  to  manage  software 
as  they  use  to  manage  hardware. 

2.  That  directives,  regulations  and  standards  written  to  cover  both 
software  and  hardware  be  carefully  analyzed  to  assure  that  software  is 
adequately  and  correctly  discussed. 

3.  Tliat  DS?X  discuss  the  management  of  software  acquisition  more.  I'any 
of  the  engineering  disciplines  discussed  in  the  Systems  Dngineering/Logis- 
tics  Management  Course  apply  to  software  as  well  as  hardware.  Yet,  soft- 
ware is  rarely  used  as  an  example.  The  two  hour  block  in  Fundamentals  of 
Program  Management  should  be  expanded  to  four  hours. 
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